home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.19970929-19971216
/
000056_news@newsmaster….columbia.edu _Sun Oct 5 21:12:51 1997.msg
< prev
next >
Wrap
Internet Message Format
|
1997-12-15
|
7KB
Return-Path: <news@newsmaster.cc.columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id VAA17581
for <kermit.misc@watsun.cc.columbia.edu>; Sun, 5 Oct 1997 21:12:50 -0400 (EDT)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id VAA05807
for kermit.misc@watsun; Sun, 5 Oct 1997 21:12:50 -0400 (EDT)
Path: news.columbia.edu!panix!news.eecs.umich.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
From: jrd@cc.usu.edu (Joe Doupnik)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Kermit via PPP under DOS?
Message-ID: <4TpKBo0duVW2@cc.usu.edu>
Date: 5 Oct 97 08:40:36 MDT
References: <k1c7kBQEU5Wv@cc.usu.edu> <omraa16rl3.fsf@tees.cs.ualberta.ca>
Organization: Utah State University
Lines: 108
Xref: news.columbia.edu comp.protocols.kermit.misc:7827
In article <omraa16rl3.fsf@tees.cs.ualberta.ca>, Vladimir Alexiev <vladimir@cs.ualberta.ca> writes:
> In article <XrKuqa+e0PBq@cc.usu.edu> jrd@cc.usu.edu (Joe Doupnik) writes:
>
>> > the fact remains that these apps can use emulated class 1 drivers, while
>> > Kermit can't. Sometimes worse is better.
>> This looks more and more like an argument waiting to happen, due to
>> lack of specific information.
>
> Talk by Michael Ringe <michael@thphys.physik.rwth-aachen.de> which is "built
> upon the WATTCP library" works with EPPPD which is a class 1 PPP driver.
> Kermit's TCP is also built over the WATTCP library (if information on WATTCP's
> site is correct), but I guess that Joe has introduced changes that make it
> incompatible with drivers emulating class 1 (Internet).
Kermit's TCP/IP stack is based upon the WATTCP of over six years ago
and followed its own development/evolutionary path to be a different set of
code. Similarly the WATTCP of that era has itself developed and evolved to
be the WATTCP of today. Neither is even nearly the same as their 1991 versions.
Today the two sets of code are very different indeed. I've said this before.
Class 1 Packet Drivers have no identification with "Internet"; we
presume that's your name for IP packets. They purport to deal with frames on
Ethernet. MS-DOS Kermit runs just fine over Class 1 Ethernet Packet Drivers,
if those drivers do their job correctly.
Again here are fundamentals and I hope you pause to understand this.
A Packet Driver advertisizing itself as Ethernet (Class 1) on the top tells
the application protocol stack that Ethernet is the lan topology and hence
Ethernet rules apply. Amongst them are supporting MAC addresses, identifying
stations in the same broadcast domain (and hence IP subnet) by physical layer
broadcasts and direct MAC addressing (no router), and having an IP gateway to
contact stations not in the same broadcast domain. An ARP for one's own IP
address, for example, must fail to yield a response, and an ARP for another
station on the same IP subnet must yield a proper response (or none if the
station is not reachable by IP at that time). This is in addition to framing
details. Ethernet runs this way.
Let me emphasize this point again. Frame construction is only part
of the situation. Supporting a broadcast medium via physical addresses is
another part, and it is the part that is easily broken in emulation. Both
parts are intrinsic components of Ethernet. See my comment on "fundamentals"
below.
If a PPP or carrier-pigeon or whatever driver advertisizes itself
as Ethernet to the protocol stack then it must emulate Ethernet
characteristics to the protocol stack.
>> I thought I explained the difficulties with a driver purporting to be
>> Ethernet but isn't; they are fundamental.
>
> How do you explain then that that talk program works? I also tried
> successfully the telnet from NUPop over the same EPPPD driver, however NUPop
> is not WATTCP-based. Would you like me to test WATTCP FTP or a WATTCP-based
> telnet client (where is one)?
>
I have not the slightest idea of what code is in those programs.
Have you looked at them to see what they do internally? How about the
internals of those PPP drivers? What are those drivers really doing?
>> > Well, these half measures prove to be adequate for other WATTCP apps.
>> which are tailored for a point to point link, no doubt.
> I don't think so. I don't have an ethernet connection I can try them with, but
> their docs claim they work over ethernet too. It wouldn't make much sense if
> they didn't.
>
>> > - there are apps that only support ethernet interfaces. Kermit couldn't
>> > coexist with such apps because it demands a SLIP interface.
>> Argumentative again. No, Kermit does not "demand" SLIP,
> If Kermit is to be used with a serial link (SLIP or PPP), the packet driver
> has to support class 6 (SLIP) interface. Obviously all SLIP drivers do, but
> only two out of the three freely available PPP drivers do (dosppp and
> MeritPPP, aka etherppp or ethernew), while ppppkt does not. More important
> however is that if one would like to use another TCP app together with Kermit,
> that app should also support class 6, because a driver can only run in one of
> the class modes that it supports at a time.
We do not support any attempt to run two TCP/IP stacks over the same
lan driver, period. Folks may be succussful at times with pktmux, but that
is not an item or area we are prepared to support in any way. Why? Because
it is not possible to cleanly separate two or more stack's this way, despite
the good work in pktmux.
>> but if the alternatives fail to meet specs then that is hardly Kermit's
>> fault.
> What spec does a working combination "class 1 PPP driver" - "class 1 app" fail
> to meet? You seem to assert that class 1 emulating serial drivers are
> impossible, yet there are at least 3 such: dosppp, MeritPPP, pppshare/pppdemo.
No such assertion has been made by me. You are the guy going to
extremes.
>> > Is BOOTP impossible with a SLIP interface? How about DHCP?
>> Both use UDP over IP. How IP gets put onto the wire is another matter.
> Yes, I can't think of a good reason why BOOTP shouldn't work either, but the
> class 6 driver in dosppp (PPPD) doesn't support it for some reason.
>
>> Please do keep in mind that both BOOTP and DHCP are sensitive to physical
>> address
> Why? Isn't it only critical for RARP (which resolves an Ether address to an
> IP address)? I guess it depends a lot on the remote side as well, because most
> often the remote gives us our IP.
It might be beneficial to review the specs of BOOTP and DHCP.
>
>> > How about Windows PPP drivers, do they support an Ethernet interface?
>
> (Forget about this, my mind was probably clouded when I wrote it; Windows
> drivers are not packet drivers.)
Joe D.